Emulation systems are used to verify electronic circuit designs prior to fabrication as chips or manufacture as electronic systems. Typical emulation systems utilize either interconnected programmable logic chips or interconnected processor chips. Examples of hardware logic emulation systems using programmable logic devices can be seen in, for example, U.S. Pat. Nos. 5,109,353, 5,036,473, 5,475,830 and 5,960,191. U.S. Pat. Nos. 5,109,353, 5,036,473, 5,475,830 and 5,960,191 are incorporated herein by reference. Examples of hardware logic emulation systems using processor chips can be seen in, for example, U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030. U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030 are incorporated herein by reference.
Emulation systems generally include a host computer (also referred to as a workstation) in communication with an emulator. The emulator can be arranged to communicate with a target system. The target system typically includes multiple electronic devices such as memory, microprocessors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc. that communicate with one another to perform specific functions. The components in the target systems are typically electronic devices that have already been developed. An example of a target system would be a computer motherboard having all ancillary chips located thereon. Using an emulator, one can verify that a chip such as a microprocessor operates as intended in the computer.
The emulator can also be used without a target system by running test vectors or a test bench. A test bench provides stimulus to the emulator's inputs and monitors and checks the emulator's outputs. A test bench can be embedded in the emulator itself or can be a software program running on another computer (typically another workstation).
The emulator mimics the functionality of a system that is being developed, which is referred to herein as a “device under test” (DUT). A device under test can be any system that includes logic that needs to be verified such as a single integrated chip, a printed circuit board with many chips, or multiple printed circuit boards each having multiple chips.
The process of designing an integrated circuit includes several phases. First, a designer creates a design (which will be the DUT) using specialized design software that runs on a host computer. Second, the design is compiled using specialized software that also runs on the host computer. The compilation process translates the DUT into a format that can be utilized by the emulator. This compilation process is very time consuming, often taking on the order of several hours to complete. Third, the user loads the compiled DUT into the emulator via the host computer. Fourth, the user emulates the DUT by running the emulator.
Unfortunately, DUTs usually have flaws or bugs that need to be fixed before they can be implemented in an actual device. Trigger circuits help the designer isolate and fix these problems. Specifically, trigger circuits allow the designer to define a trigger condition, which is based on an event or series of events that occur during emulation of the design. When the trigger condition is met, an action is taken. For example, upon detection of the trigger condition, a data collection mechanism called a trace buffer, which continuously collects and stores signal values from the emulated design, is instructed to stop, or the design running in the emulator may be stopped.
Trigger circuits can be simple or complex. A simple trigger circuit can evaluate the values of a predetermined set of signals in the design. For example, if A, B, and C are signals in the design, a trigger could be defined simply as follows: A=0 & B=1 & C=0. In this case, when the values of these three signals match their expected values of 0, 1, and 0, respectively, the trigger circuit would produce a signal indicating that the trigger condition has been met. A simple comparator circuit could be used to produce this trigger signal. Triggers can also be based on more complex combinations of signals within the design. Using a more complex trigger circuit, a different set of conditions can be tested each cycle, and based on the result the system decides whether to issue a trigger signal or not and what set of conditions to test in the next cycle. A state machine could be used in the trigger circuit in this case. Regardless of the flexibility or complexity of the trigger circuit, the trigger condition is based on signal values that are accessible from within the emulator. Such signal values may be any signal that is accessible inside the emulator, whether generated within the design under test, a test bench embedded inside the emulator or input from an external test bench or a target system.
Conventional trigger circuits suffer from several shortcomings. First, the topology of these circuits cannot be changed after the design is compiled for programming inside the emulator. For example, a user will have to define a set of signals that can participate in a trigger condition during the design phase. At the completion of the design phase, the DUT and the user defined trigger circuit are compiled into a format that can run on an emulator. If the user wants to use a different set of signals for the trigger condition during run time, the user will have to recompile the entire DUT with the new trigger circuit, which can take several hours or even days, depending upon the size and style of the design and the emulator technology. Even if run time routing of arbitrary signals to the trigger circuit was possible, if the desired signal is eliminated by the compiler as a result of an optimization stage, then the entire design would have to be recompiled to ensure that the signal is not optimized out, which again would take several hours or days. “Optimized out” means that the signal is not directly emulated because it was eliminated during design compilation as part of an optimization step. This happens because the compiler must take the user's logic and optimize it for use in the emulator in order to save emulation resources. Thus, the compiler may replace the user's logic with functionally equivalent logic.
Second, even though conventional trigger circuits can have some programmability, the complexity of the conditions that can be defined as triggers during run time is very limited. This is because the topology of the trigger circuit cannot be changed after the design is compiled. Simple trigger circuits are limited to the definition of a comparison between the set of specified signals and their expected values. In more advanced trigger circuits, a more sophisticated structure, such as a lookup table, is used to combine results from several such comparison circuits. But in either case, it is nearly impossible to define an arbitrary Boolean condition from the given set of signals that can be used as a trigger condition.
In view of the foregoing, a need exists for an emulation system having an improved trigger mechanism.